1. Field of the Disclosure
This disclosure relates generally to concurrent access to shared objects, and more particularly to a system and method for implementing a transactional memory that exploits hardware transactions to validate and/or commit results of software transactions, in some cases.
2. Description of the Related Art
The multi-core revolution currently in progress is making it increasingly important for applications to exploit concurrent execution in order to take advantage of advances in technology. Shared-memory systems allow multiple threads to access and operate on the same memory locations. To maintain consistency, threads must often execute a series of instructions as one atomic block, or critical section. In these cases, care must be taken to ensure that other threads do not observe memory values from a partial execution of such a block. Such assurances are important for practical and productive software development because without them, it can be extremely difficult to manage the interactions of concurrent threads. Traditional constructs, such as mutual exclusion and locks may be used by a thread to ensure correctness by excluding all other threads from concurrent access to a critical section. For example, no thread may enter a critical section without holding the section's lock. While it does, all other threads wishing to execute the critical section must await the lock's release and acquire it before proceeding.
The pitfalls of these constructs are numerous and well known. They include dead-lock, priority inversions, software complexity, and performance limitations. Locking large sections of code and/or code that accesses a lot of data is a heavy-handed approach to concurrency control.
Alternatively, it may be possible to increase parallelism by allowing multiple threads to execute a critical section at one time if the executions do not rely on overlapping memory locations. This may increase performance and mitigate many of the pitfalls normally associated with traditional locking mechanisms. However, it may be difficult (if not impossible) and cumbersome to generate code such that interleaved executions are guaranteed to be correct, i.e. that critical sections do not access memory locations in common.
Transactional memory is a mechanism that can be leveraged to enable concurrent and correct execution of a critical section by multiple threads. Transactional memory allows a thread to execute a block of instructions either completely and atomically or not at all. As typically defined, a transactional memory interface allows a programmer to designate certain sequences of operations as “atomic blocks” and “transactions,” which are guaranteed by the transactional memory implementation to either take effect atomically and in their entirety (in which case they are said to succeed), or to be aborted, such that they have no externally visible effect (in which case they are said to fail). Thus, with transactional memory, it may be possible in many cases to complete multiple operations with no possibility of another thread observing partial results, even without holding any locks. The transactional memory paradigm can significantly simplify the design of concurrent programs. In general, transactional memory can be implemented in hardware (HTM), in software (STM), as a hybrid transactional memory system (HyTM), or as a phased transactional memory system (PhTM). In HyTM and PhTM systems, the transactional memory employs hardware transactions for implementing some atomic transactions and employs software transactions for others.
Typically, a significant part of the overhead of committing a software transaction is due to the number of expensive synchronization operations (e.g., compare-and-swap type operations) that are performed in order to acquire ownership of locations to be written, and/or to increment committing indicators and subsequently decrement those indicators after completing a write back operation for the transaction. Some current HyTM and PhTM systems attempt to execute user transactions using hardware transactions. If a hardware transaction fails, one of these systems might retry it using hardware, but if it keeps failing, the system eventually resorts to the use of software transactions, which is much more expensive. Some HyTM or PhTM systems include so-called “best-effort HTM” (BEHTM), which is not required to commit all possible transactions, but which can simply abort a transaction in response to attempts to execute unsupported instructions or commit transactions under difficult scenarios and events, or when hardware resources are exhausted. In such systems, when and if they switch from using a hardware transaction to using a software transaction to execute a user transaction, the entire user transaction is performed within a software transaction. In other words, such systems either execute the entire transaction (including the user code) as a hardware transaction or execute the entire transaction in software.